Keir Fraser [Wed, 27 Aug 2008 13:53:39 +0000 (14:53 +0100)]
hvm: Use main memory for video memory.
When creating an HVM domain, if e.g. another domain is created before
qemu allocates video memory, the extra 8MB memory ballooning is not
available any more, because it got consumed by the other domain.
This fixes it by taking video memory from the main memory:
- make hvmloader use e820_malloc to reserve some of the main memory
and notify ioemu of its address through the Xen platform PCI card.
- add XENMAPSPACE_mfn to the xen_add_to_physmap memory op, to allow
ioemu to move the MFNs between the original position and the PCI
mapping, when LFB acceleration is disabled/enabled
- add a remove_from_physmap memory op, to allow ioemu to unmap it
completely for the case of old guests with acceleration disabled.
- add xc_domain_memory_translate_gpfn_list to libxc to allow ioemu to
get the MFNs of the video memory.
- have xend save the PCI memory space instead of ioemu: if a memory
page is there, the guest can access it like usual memory, so xend
can safely be responsible to save it. The extra benefit is that
live migration will apply the logdirty optimization there too.
- handle old saved images, populating the video memory from ioemu if
really needed.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Keir Fraser [Wed, 27 Aug 2008 09:11:33 +0000 (10:11 +0100)]
x86: Assert in_irq() while processing guest-bound interrupts.
Actually a fair amount of infrastructure is onvolved these days, and
we'd like subsystems we call into know that we're in IRQ context so
they can handle that or BUG/ASSERT if appropriate.
Keir Fraser [Wed, 27 Aug 2008 08:46:38 +0000 (09:46 +0100)]
PyGRUB: fix menu flicker
To avoid flickers, PyGRUB has to avoid spurious ncurses refresh as
much as possible, in particular before the complete screen is drawn,
and eventually call doupdate last.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Keir Fraser [Tue, 26 Aug 2008 13:11:39 +0000 (14:11 +0100)]
vtd: do FLR before xc.domain_destroy()
When we "xm destroy" a guest with assigned devices, in
xen/common/domain.c:domain_kill(), we relinquish guest's memory first,
then invoke domain_destroy() -> complete_domain_destroy() ->
arch_domain_destroy() -> pci_release_devices()/iommu_domain_destroy().
Between relinquish_memory() and domain_destroy(), a device may be
issuing DMA request and access guest's relinquished memory.
We can do_FLR() to quiesce devices before xc.domain_destroy().
Keir Fraser [Mon, 25 Aug 2008 13:03:42 +0000 (14:03 +0100)]
x86: Time rendezvous function does not need to disable/enable IRQs.
Since rendezvous happens within the IPI handler, no need to specify
'wait' to on_each_cpu().
Keir Fraser [Tue, 19 Aug 2008 14:56:31 +0000 (15:56 +0100)]
x86_emulate: Do not request emulation of REP instructions beyond the
point at which the index register (SI/DI) wraps. This can cause a
discontinuity in the address range accessed by the repeated
instruction.
Keir Fraser [Tue, 19 Aug 2008 09:51:41 +0000 (10:51 +0100)]
vtd: Don't do FLR when we create domain or hotplug device into guest.
VT-d hot-plug is done in such a way: 1) xend sends 'pci-ins' command
to ioemu via xenstore; 2) ioemu creates pass-through device and raises
SCI to guest OS; guest OS loads device driver, and device driver
initializes the hot-plugged device; 3) xend does FLR. There is a race
condition about 2) and 3). If 3) runs slow, we have troubles. Thanks
for Yuji Shimada's locating the issues.
We can work around the issues by not doing FLR when we create domain
or hotplug device into guest, namely, we only do FLR when we destroy
domain or hotplug device from guest.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Keir Fraser [Fri, 15 Aug 2008 13:59:41 +0000 (14:59 +0100)]
x86, hvm: Fix softtsc for AMD-V
The softtsc code for AMD does not update the ip; enabling it on AMD-V
results in the domain spinning on the RDTSC instruction. The patch is
against xen-unstable 18331.
Keir Fraser [Thu, 14 Aug 2008 09:18:08 +0000 (10:18 +0100)]
Fix restore crash with certain guest memory sizes
This fixes a crash when restoring guests with certain memory sizes (eg
223MB). The ROUNDUP in the call to memcpy, was the main offender, but
I didn't care for the inplace resizing of the p2m entries either.
Keir Fraser [Thu, 14 Aug 2008 09:14:32 +0000 (10:14 +0100)]
x86, shadow: Fix OOS on domain crash.
I couldn't reproduce the Nevada crash on my testbox, but this should
fix the first Xen crash that was seen in the Nevada HVM (bugzilla
#1322).
What I think most probably happened there is that the set_l2e call in
shadow_get_and_create_l1e() has tried to resync a page, but somehow we
weren't unable to remove the shadow (the real bug we should actually
look after). sh_resync() then removes the page from the OOS hash and
later in the page fault path we find the gw.l1mfn to be still OOS, so
we try to update the snapshot and the bug happens.
This should fix this and other unlikely (like sh_unsync() failing to
remove for hash collision the current gw.l1mfn) cases.
Keir Fraser [Wed, 13 Aug 2008 11:13:59 +0000 (12:13 +0100)]
x86: Fix shadow code's handling of p2m superpage changes
When a p2m superpage entry is shattered, it's important not to
unshadow any parts of the 2MB region that are still there afterwards.
Otherwise shattering a superpage that contains the guest's top-level
pagetable will cause the guest to be killed.
Keir Fraser [Mon, 11 Aug 2008 10:27:40 +0000 (11:27 +0100)]
xend: Better support for legacy HVM config of ia64
On ia64, direct Linux boot is not supported, and 'Flash.fd' or
'guest_firmware.bin' has been used as a value of the 'kernel'
option. Cset:17016 ignores those strings and overrides them with
"/usr/lib/xen/boot/hvmloader".
Isaku Yamahata [Mon, 11 Aug 2008 01:59:39 +0000 (10:59 +0900)]
[IA64] Print ACPI signature before overwriting it
We're printing out the ACPI table signature after we overwrite it
with "OEMx". Let's print it out before so we know that the table was.
Also limit print to 4 chars so we don't get garbage output.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Keir Fraser [Fri, 8 Aug 2008 09:53:40 +0000 (10:53 +0100)]
ia64: PV driver domains - ugly python hacks
x86 IOMMU support added a lot of assumptions about what PCI buses look
like and where to find bridge devices. On ia64, we don't yet have
virtualization friendly IOMMUs, so for the moment, we just want to
keep "unsafe" PV PCI pass through working as well as it did in Xen
3.2. Looking at the code, it almost seems like x86 has thrown out
support for the old style driver domain. Things that don't
necessarily work on every PCI compliant architecture:
* You can't assume that just because there's a device at 01:01.0
that there's also a bridge at 01:00.0 and blow-up when you
don't find it. On HP ia64 boxes, PCI root bridges are not
necessarily exposed as a PCI device. This pretty much means
we can't call into any of the "FLR" code paths.
* BAR alignment: it's hard to have BAR alignment when your page
size is 16k. This wasn't a requirement for previous PV driver
domains, so I assume it's only for IOMMU support.
This is ugly, so I'm open to suggestions. It seems that all of these
architecture checks could be replaced by checking some "iommu_present"
variable to test whether the extra requirements are necessary.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Isaku Yamahata [Fri, 8 Aug 2008 02:38:21 +0000 (11:38 +0900)]
[IA64] Remove VT-i no opcode warning
I've never been sure why we have such a big scary warning around this,
when I have yet to see any system that does provide opcode decoding.
Let's remove it.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Isaku Yamahata [Fri, 8 Aug 2008 02:38:20 +0000 (11:38 +0900)]
[IA64] Cleanup ACPI checksum warnings
On bootup, I get a couple of these:
(XEN) ACPI Warning (tbutils-0219): Incorrect checksum in table [APIC] - CE, should be 04 [20070126]
(XEN) ACPI Warning (tbutils-0219): Incorrect checksum in table [APIC] - CE, should be 04 [20070126]
I don't remember seeing them before, but they're pretty easy to fix.
The problem is we update the lsapics, causing the checksum to be wrong,
then we look for platform interrupt sources, which spits out a warning,
and finally we look for the MADT again to fix the checksum, which also
prints a warning. If we grab a pointer to the MADT before these, we can
update the checksum after each step and avoid the warnings.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Isaku Yamahata [Fri, 8 Aug 2008 02:38:17 +0000 (11:38 +0900)]
[IA64] backport EFI version warning fix
We have boxes that report EFI version 2.00 now, so adopt upstream linux
patch to only warn on versions less that 1.00. Based on linux-2.6.git 873ec746158403af82c57ce26780166aafc159e1.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Isaku Yamahata [Fri, 8 Aug 2008 02:38:08 +0000 (11:38 +0900)]
[IA64] Fix PV driver domains - xen stubs
Stub out new hypercalls in the hypervisor. The only odd one here is
map/unmap_pirq. This seems to be for MSI support, which I don't believe
we currently support for driver domains, so this is actually similar to
the x86 code path. The tools code doesn't allow us to return -ENOSYS
here :(
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
projects / xen.git / log